Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a one or a set of “models” consisting of a set of block diagrams and associated objects. System implementation typically entails automatically generating code for portions of a model, particularly portions corresponding to the system's control algorithm.
Graphical modeling environments are programs that enable a user to construct and analyze a model of a process or system. Examples of graphical modeling tools include time-based block diagrams, such as Simulink from The MathWorks Inc., state-based and flow diagrams, such as those found within Stateflow® also available from The MathWorks, Inc., data-flow diagrams, such as LabVIEW, available from National Instruments Corporation, and software diagrams and other graphical programming environments, such as Unified Modeling Language (UML) diagrams.
Some graphical modeling environments also enable simulation and analysis of models. Simulating a dynamic system in a graphical modeling environment is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system is simulated using the information entered into the graphical model. In this step, the graphical model is used to compute and trace the temporal evolution of the outputs of the dynamic systems (“execute the graphical model”), and automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (code generation).
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a first collection of graphical objects, such as nodes, that are interconnected by another set of graphical objects, generally illustrated as lines, which represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant when enabled. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship among the signals and between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination node of this signal are read from the signal when their system equations are being solved. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
It is worth noting that block diagrams are not exclusively used for representing time-based dynamic systems but also for other models of computation. For example, in Stateflow®, flow charts are block diagrams used to capture process flow and are generally not suitable for describing dynamic system behavior. Data flow models are block diagrams that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks.
As systems become more complex and require ever more signals for passing data, it becomes beneficial to be able to group or otherwise combine signals in the graphical model of the system. One current method of combining signals is using a bus creator to create a bus signal. An example of a bus signal and its bus creator can be seen in the block diagram 100 of FIG. 1A. Here, multiple signals 110a, 110b, and 110c are provided to the bus creator 120 which in turn produces the bus signal 130. In this case the attributes of the data in the bus signal 130, such as dimension and data type, are determined by, or inherited from, the system. In this case, signals 110a, 110b, and 110c that were combined to make the bus signal 130. One limitation of this method is that it does not allow for operations to be performed on specific signals in a bus signal. To perform an operation on a specific signal, the bus signal 130 must first be separated back out into its components signals 110a, 110b, and 110c before an operation can be performed on the specific signal. In this example a bus converter 140 is used to separate the bus signal 130 into the component signals 110a, 110b, and 110c so that a delay 150 may be performed on signal 110a. 
Another option for creating a combined signal is creating a class object. An example of an editor used in creating such a class object can be seen in FIG. 1B. With a class object, all the attributes, such as dimension 160 and signal type 170, for the signals comprising the object are predefined or specified, which allows for operations to be performed on the individual signals of the object. This is also one of the limitations of the class object because for every instance of such an object, even though the execution attributes such as sample time can be inherited, all the operation attributes need to be pre-defined or specified for the object to work in the system.
Handling execution attributes such as the sample time and frame rate of a signal is dissociated from the operations that are performed on a signal and that process the data on the incoming signal to data on the outgoing signal. Therefore, the inheritance of such execution attributes does not affect the actual operations. As such, the execution attributes are of a different nature than the operation attributes, as the operation attributes require inherent modifications to the operations that perform the data processing.
As the system grows more complex and requires more and more signals, the requirement of defining all the operation attributes for each object necessary for representing all the signals becomes more complex and tedious which in turn increases the likelihood of errors.
Therefore, what is needed is a method of combining and handling multiple signals that does not suffer from the above limitations of needing to decouple the signals to perform an operation or requiring that every attribute of the operation be predefined for each instance.